SSL is a convenient, secure way to encrypt
communications. It’s well understood by IT organizations, it is
firewall friendly, and there are many management and performance tools
on the market. Using SSL with BasicHttpBinding enables the broadest reach of a secure Web service.
SSL
requires a digital certificate with an asymmetrical (public/private)
key to establish an encrypted pathway. After it is established, SSL
uses this pathway, with a more efficient symmetric encryption
algorithm, to encrypt messages going both ways on the channel.
A
digital certificate can be obtained from a number of sources. There are
public entities, such as Verisign, that issue certificates for testing
and production purposes. Windows Server itself ships with a certificate
issuing service, so you can generate your own certificates that can be
trusted by your organization or partners. In addition, .NET ships with
a utility, MakeCert, which generates certificates for testing purposes.
SSL over HTTP
SSL
can be applied to most transport protocols (a notable exception being
queued transports), but it is most commonly used with HTTP. When using
a binding based on the HTTP transport, whether you’re hosting the
services in IIS or self-hosting in another process, HTTP.SYS must be
configured for SSL. For IIS, you can add the binding using the IIS
Administration tool. For IIS 7, this is done by selecting the Web site
under which the virtual root is defined, and then selecting the
Bindings link in the Actions pane. This will launch a dialog from which
you can select the certificate to use for SSL communications (see Figure 1).
For self-hosting a service on Windows Server 2008 or Vista, you can use the netsh tool. Listing 1
shows the command line to configure HTTP.SYS to allow SSL traffic on
port 8001. Specifying IP address 0.0.0.0 indicates all IP addresses.
The 40-digit hex number is the thumbprint of a certificate installed on
the machine. The thumbprint can be found by using the Certificates
Add-In in the Microsoft Management Console and viewing the certificate
details. The final GUID is an application identifier, representing who
enabled this access. Any GUID that you generate is acceptable here and
will be associated with your application.
Listing 1. Using NetSh to Configure HTTP.SYS to Allow SSL on Different Ports
90
netsh http add sslcert 0.0.0.0:8001
1db7b6d4a25819b9aa09c8eaec9275007d562dcf
{4dc3e181-e14b-4a21-b022-59fc669b0914}
|
After you’ve registered the certificate with HTTP.SYS, you can then configure a service to use SSL encryption. Listing 2 shows a service configuration file that is using the basicHttpBinding
binding, transport-level encryption, and no client authentication. Note
that two base addresses are specified in this self-hosted configuration
file, one for encrypted and one for non-encrypted communication. This
enables the MEX endpoint to use a non-encrypted channel and the
subsequent communication to be encrypted. If you don’t want to expose a
MEX endpoint, or if it is okay to expose it on a secure channel, you
don’t need the non-encrypted address.
Listing 2. Encryption with basicHttpBinding
90
<system.serviceModel>
<services>
<service name="EffectiveWCF.StockService"
behaviorConfiguration="MyBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8000/EffectiveWCF" />
<add baseAddress="https://localhost:8001/EffectiveWCF"/>
</baseAddresses>
</host>
<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="MyBinding"
contract="EffectiveWCF.IStockService" />
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="MyBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="MyBinding">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security >
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
|
SSL over TCP
Like
HTTP, the TCP transport can be used with SSL for encrypted
communication. Configuration options for specifying transport security
for TCP are similar to HTTP. To configure a service to use the TCP
security, three changes must be made to Listing 2.
First, the binding specified for the non-MEX endpoint is NetTcpBinding rather than basicHttpBinding.
Second, the base address of the service should be a TCP URI address
rather than an HTTP URI, of the form
net.tcp://{hostname}[:port]/{service location}. Third, a NetTcpBinding configuration should be used rather than a basicHttpBinding configuration to specify the <Security mode="transport"> setting. Listing 3 shows this configuration.
Listing 3. Encryption with NetTcpBinding
90
<system.serviceModel>
<services>
<service name="EffectiveWCF.StockService"
behaviorConfiguration="MyBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8000/EffectiveWCF" />
<add baseAddress="net.tcp://localhost:8002/EffectiveWCF" />
</baseAddresses>
</host>
<endpoint address=""
binding="netTcpBinding"
bindingConfiguration="MyBinding"
contract="EffectiveWCF.IStockService" />
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="MyBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<netTcpBinding>
<binding name="MyBinding">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security >
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>
